突撃！隣のDevOps 【はてな編】

突撃！隣のDevOps

#DevOps

かたいなか

2019.02.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは、DevOps支援室のかたいなかです。

今回は、株式会社はてなさんの京都オフィスに伺い、はてなさんのDevOpsに対する取り組みや考え方についてガッツリインタビューしてきました！

はてな紹介

どのようなサービスをやっている

「はてなブックマーク」「はてなブログ」などのソーシャルサービスや、サーバ監視SaaSである「Mackerel」などを開発・提供しています。また任天堂様やKADOKAWA様との共同開発や、集英社様、講談社様などが運営されているWebマンガサービスへのビューワ提供にも取り組んでいます。

担当者の方の仕事内容

具体的にどのような仕事をしているのか

motemenさん
- CTO
- 技術的な方針策定、エンジニア組織マネジメント。技術的な知見をどうチーム間で共有していくのか、とか、プロダクトの技術的な基準とか。評価設計と運用とか。採用とか。
- ログイン、人力検索はてな、はてな匿名ダイアリー等昔からあるのサービスを担当するチームでは、アプリエンジニアとしても稼働
wtatsuruさん
- サービス・システム開発本部/システムプラットフォーム部長/チーフエンジニア
- 基盤チーム、システムプラットフォーム部の方針策定
  - プロダクトオーナーシップに向けた取り組み
  - 開発チームの運用支援
  - DC移転プロジェクト
- 普段のチームマネジメント
  - プロジェクト管理、人員管理、予算管理
songmuさん
- サービス・システム開発本部/Mackerelチーム/サブプロデューサー兼チーフエンジニア
- Mackerelのプロダクトの意思決定。ロードマップ・仕様策定
- 新しいインフラトレンドのリサーチ
- 執筆なども「入門監視」「Mackerelサーバ監視実践入門」「みんなのGo言語」
astjさん
- サービス・システム開発本部/Mackerelチーム/テックリード
- 機能開発、ソフトウェア保守
  - いわゆるコードを書く仕事。ユーザ向けの機能開発からライブラリの更新やリファクタリングなど。
- 開発エンジニアの意見集約、開発スケジュールへの反映
- 担当サービスのインフラ運用、基盤チームとの折衝
hokkai7goさん
- サービス・システム開発本部/SRE
- 各プロダクトの開発チームがインフラの環境構築、新たな技術の本番投入などができるように知見獲得を促進するプロジェクト
- 新たな基盤の設計、構築、バージョンアップ作業
- 割れ窓タイムの企画、運用

左からastjさん、wtatsuruさん、motemenさん、songmuさん、hokkai7goさんです。

DevOpsについて

文化

御社の考えるDevOpsの定義とは？

はてな社内ではDevOpsと言う言葉自体を意識することが少ないそうです。ですが、あえて定義していただくとすると以下のようになるそうです。

SRE(インフラエンジニア)とアプリケーションエンジニアの双方の理解が進み円滑に仕事が進めるための考え方、文化(hokkai7goさん)

ユーザや社会にもたらす価値と、その持続可能性を最大化できている体制(motemenさん)

Effective DevOpsより「持続可能な組織文化の育て方」(Songmuさん)

なぜDevOpsに取り組んでいるのか？

まだ規模が小さかった頃は、サーバ自体も自分たちで作っていました。その後、エンジニアにはサービス開発に集中してもらえるように、仮想化基盤を作りました。そのころはシステムが同じような構成だったので良かったのですが、共通基盤に引きずられて、各サービスの進化、開発速度が上げられない状態になってしまいました。(wtatsuruさん)

インフラのことはインフラエンジニアに聞かないとわからない、といった状態も発生してしまっていたそうです。例えば、VMを立てるのを一つとっても、インフラエンジニアに依頼しないといけないような状態も発生したそうです。

その結果、Opsは運用負荷が高まり、Devは自分たちの責任で技術選択ができないという状態になってしまっていたそうです。

このような状態を改善し、SRE(インフラエンジニア)とアプリケーションエンジニアが協力、連携して素早く良いプロダクトを作り上げていけるようにしようと、プロダクトオーナーシップという言葉を使って活動しているそうです。インフラエンジニアと開発エンジニアの間の知識移転をサポートしながら、チームとして上から下まで見られる状態を目指しているそうです。

各チームでインフラまで見られるようにして、どんどん改善し、変更速度を上げていけるようにしたいと考えています。基盤やインフラ技術そのものは、SREの理解が先行しています。一方で、サービスの知識についてはアプリケーションエンジニアが深く理解しています。そうしたお互いの理解を突き合わせていくために、DevOpsに取り組んでいます。(motemenさん)

SREとアプリケーションエンジニアの間の理解を深め、円滑に仕事が進められるようになることが、提供できている価値を最大化することにつながっていくと考えているとのことでした。

基盤として用意された最大公約数的な構成より複雑度の高いシステムを保守・運用するにあたっては、採用技術への理解とプロダクト・サービス特性への理解を両立させる必要がある。プロダクト担当チーム内でDevとOpsの両輪を回すことでそれに近づける。(astjさん)

技術的な自由度を高め、開発者が自分たちの責任で技術選択をできるようにするにはDevとOpsがもっと近づく必要があるとのことでした。

DevOpsにおいて重要な考え方とはなにか？

目的意識、立場を取り払った学習が大事だと考えています。(motemenさん)

明確な目的意識を持っていれば、インフラエンジニア、開発エンジニアといった立場はなくなっていくとのこと。みんなでプロダクトの価値を作っているのだという意識をもち、立場を取り払った学習を行うことが重要とのことでした。

DevとOpsをどのように連携させているのか？

ある程度トップダウンに、開発チームが上から下まで見られるようにしようと定めた、そのためのノウハウ獲得をサポートしていく動きを作っていった。(motemenさん)

具体的な知識移転の取り組みとしては、SREによる勉強会を実施したり、サービスにSREをつけるなどして知識移転を促進させるようにしているとのことでした。

チームのメンバー構成はどうなっているのか？

Mackerel 開発チームは以下のような構成だそうです

PO(Songmuさん) 1人
ディレクター 1人
開発エンジニア 7人
SRE 1人
デザイナー 2人
翻訳 1人

SREや開発エンジニアという職種によって開発・運用のタスクを機械的に分配しているのではなく、各人の得意不得意にあわせて分担しているそうです。SREは本来コードを書くものだと考えており、現在もコンテナ監視用のエージェントのコードを書いてもらっているとのことでした。

新メンバーへのキャッチアップの支援をどのようにやっているか？

新メンバー向けのしっかりとした資料があり、その資料を使用した説明会を最初に実施しています。その上で、その人のレベル感次第で調整しながらプロダクトの構成を見て改善ポイントなどを発表する研修などを行い、OJTにうつります。(hokkai7goさん)

新メンバー向けのしっかりした資料があるそうです。それらの資料ではポインターでいろいろな資料に飛べるようにもなっているそうです。

また、ペアオペやモブオペなど、知見を共有していくための取り組みも積極的に行っているそうでした。

また、Mackerelチームでは当番制を敷いており、デプロイやOSSリリース、アップデートなどについてチームメンバーが交代で取り組むことで業務が属人化するのを防いでいるそうです。

最近割れ窓タイムというものを実施しており、メンバー間での知識の差が如実に現れるので、これも新メンバーへのキャッチアップ支援となっています(hokkai7goさん)

改善が必要だが優先度が低く対応が後回しになってしまいがちな「割れ窓」タスクを解決するため、割れ窓タイムとして割れ窓タスクを解決するためのの時間を設定しているそうです。

取り組みやすそうなissueを「週刊割れ窓マガジン」にまとめ、取り組むタスクを決めるときに参考にしてもらっているそうです。

参考：割れ窓理論をWebインフラの改善に活用し、チーム内の知識共有を促進している話

DevOpsを進めていく上で苦労したことなどはなにか？

開発チームが今まで見ていなかったものを見てもらっているので負担はあります。そのために、各チームにSREに入ってもらい対策をしています。(motemenさん)

開発チームとしてインフラのことまで見るようになったため、知識移転が負担になった面はあったそうです。しかし、一度Chefのリポジトリを触れるようになると、アプリケーションエンジニアも驚くほどすごく触ってくれるようになったそうです。

プラクティスとツール

CI、デプロイ、構成管理どのようにやっているのか？

CI は主にJenkinsを使用し、テストジョブ自体はほぼ Docker で完結させています。デプロイはCapistranoが多いです。(astjさん)

サーバの構成管理については基本的に社内基盤のChefを利用している事が多いです。サービスごとのcookbookがあり、ミドルウェアのcookbookを呼び出すという感じで、うまく抽象化されています。 Mackerelのロールとサービスのcookbookが連携する形で作られており、新規サーバを立ち上げると、そのロールのCookbookが勝手に走るようになっています。(hokkai7goさん)

社内基盤のChefがあり、それを利用する構成となっている部分が多いとのことです。Chefの冪等性を保つのが大変なので、今後はなるべく作ったサーバをすぐ捨てられるようにしていきたいとのことでした。

また、ソースコードの管理はGitHub Enterpiriseを使用しているそうです。

そして、Mackerelチームでは一部Kubernetesを本番運用しており、そこではskaffold deployで反映しているそうです。社内基盤への依存がほぼないためChefを使わずにkuberspray経由でTerraform / Ansible を利用しているとのことでした。

また、今後は各チームがインフラまで見られるようになり、各サービスごとに最適なものを選んでいってほしいとのことでした。

自動テストは、どのレイヤにどの程度行っているのか？

基本的にユニットテストのみ自動化しています。ユーザがサーバにインストールする mackerel-agent の apt や yum のパッケージリポジトリについては、 Docker 下でインストール可能か、といった受け入れテストも自動化しています。テストが通ったものは自動的にステージングまでデプロイされるところまでCIの一貫として実施しています。(astjさん)

また、はてなの古いサービスのコードにはテストがない状態も多いそうです。そういった場合には新しく触るところにはテストを書くようにしたり、早めに切り戻しを行えるようにするなどして品質担保を行っているとのことでした。

障害をどのように検知して、どのような対応フローで進めているのか？

メトリクスの取得や外形監視、ログ監視についてはMackerelを使用しています。ログ分析に Kibana も利用しています。Slackに各サービス、全インフラアラートが出てくるチャンネルがあり、SREは自分の担当サービスや全インフラアラートが出るチャンネルを見ています。障害発生時にはこうしたチャンネル上で話しながら対応し、そのうえで、取りまとめ役（テックリードとか）が障害ドキュメント（いわゆるポストモーテム的なもの）を書き、障害告知や状況把握や報告に使うようにしています。(hokkai7goさん)

障害ドキュメントについてはアルバイトやエンジニア以外の職種の方も含めた社内の誰でも見られるようにしているそうです。

参考：社内障害情報共有のススメ

チャットツールなど補助的なツールはどのように使っているか？

コミュニケーションツールについてはSlackとはてなグループの２つが使用されているそうです。

はてなグループは社内ブログの集合体みたいなもので、いろんなトピックが日々投稿されるなかに、システムプラットフォーム部からのお知らせが周知されたりするものだそうです。

Slackで今回の記事の内容に関連したものですと、以下のようなチャンネルがあるとのことでした。

チームごとの#infra_xxxチャンネル
- 開発チームと基盤チームの SRE が両方入っており、作業ログや、アラートもここに流すようにしているそうです。
- 例えば #infra_blog
#ask-infra
- 困ったらとりあえず聞くチャンネル
- 他のチャンネルで:saba:リアクションつけたらここに流れてくるようにしているそうです。

Mackerelチームではどこでどんなチャネルがあるかわかるように、チャンネルのリストを管理しているそうです。プライベートのチャンネルも存在は公開し、プライベートである理由を説明するようにしているとのことでした。

また、CTOのmotemenさんが開発された、furoshiki2 というツールで作業ログを記録・共有しているそうです。コマンドのラッパーとして機能し、サーバー上で行った作業のログをGitのリポジトリとSlackに記録しているそうです。

参考：作業ログと履歴をシンプルに共有できる furoshiki ってツールを書いた

どのようなメトリクスを取得して、どのように改善をおこなっているのか？

10年ぐらい前からPWG(パフォーマンスワーキンググループ)という、プロダクト開発チームとインフラチームが月に1回改善を検討する会議を設けています。Mackerelで作成したダッシュボードを見ながらインフラ状況の変化を見ます。エラーレートを見て、値が大きく変化したりしている事象について、既知の事象かどうかを確認しています。(wtatsuruさん)

具体的なメトリクスとしては以下のようなものを見ているそうです
- エラーレート
- CPU使用率は積み上げ
- Disk I/O
- スループット
- バッチのcronの所要時間
  - 処理時間をトラッキングし、長い時間がかかっているものを分割するか議論する材料に
- 外形監視の処理(クローリング)時間
  - 1分以内でクローリングが終わっているか

メトリクスをきちんと取得していることで、今まで40秒かかっていたものが20秒になった等、開発者の成果が目に見えるようになったそうです。目に見える結果が、エンジニアの評価材料にもなっているとのことでした。

最後に

目指すところはどこか？

motemenさん

はてなという会社でどういう価値を出せるかを追求する際に、技術がネックにならないようにしていきたいと思っています。チームとして価値を出せている状態を作り出したいです。

wtatsuruさん

ものすごいスピードアップができてるかといえば、まだできていないと思っています。継続的に支援していき、はてなのサービスの信頼性、開発速度を上げる基盤を創っていきたいです。

songmuさん

Mackerelとしては、監視、オペレーション、DevOpsの未来を製品として示したいと考えています。最近だと、Envoyのような革新的なソフトウェアが登場し、オブザーバビリティを高くする敷居が下がってきたので、うまくとりこんでいきたいと考えています。

Mackerelチームとしては属人性を減らし、強い組織を目指したいです。

astjさん

より品質の高いものをスピード早く提供したいです。Kubernetesをはじめ、新しいアーキテクチャ、考え方を採用していきながらも、組織として特定個人が抜けても持続可能性を保ちたいです。

hokkai7goさん

DevとOpsの壁がない状態を作りお互いを信頼してサクサクとプロダクト開発と運用改善をポジティブに行っていきたいです。サーバやプロダクトの新陳代謝を高めていきたいです。

採用募集中

はてなさんでは現在全方位にエンジニアを募集中とのこと。はてなのミッションに共感し、一緒にサービス開発に取り組んでくれるエンジニアを求めているそうです。事業成長に伴い、やれること・やりたいことも増えてきているので、ぜひ採用ページやはてな開発者ブログを覗いてみていただけると嬉しいです！とお話されていました。